This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
So the problem is just that the UNO api is complex
That's inherited from OpenOffice so its not likely it can be transformed into something simpler in an instant, it's what's available and what OpenOffice developers use.
Not sure what you mean by this though:
Next, they learn there is not a real COM API for UNO, but more of a 'let's shove java code into OLE/COM so we can get some stuff done.
I don't think there is java involved in the COM interface. I think that what actually happens is that OO wraps a COM factory around a UNO multi-service factory and wraps OLE objects around UNO objects. This makes the UNO api available via COM in a pretty sensible way. That seems very similar to the notes COM api which puts an OLE wrapper around the notes object model. The Notes object model also supports a java binding but that doesn't mean the notes COM interface somehow involves java or that the notes COM api is not "real". Both these COM interfaces are "real" and they make the underlying product API available via COM. In the case of Symphony, which is to say OpenOffice, the underlying product API is not simple, but there it is, its what there is to work with right now.
Feedback response number MLES7C7NY6 created by ~Jennifer Minjipymanader on 02/26/2008